AUG. 31.2006 4:01PM ZILKA-KOTAB. PC 

-19- 

REMARKS 



NO. 4050 P. 26 



The Examiner has rejected Claims 1-90 under 35 U.S.C. 112, second paragraph, 
as being indefinite. Such rejection is deemed moot in view of the clarifications made 
hereinabove to the claims. 

The Examiner has rejected Claims 1-94 under 35 U.S.C 103(a) as being 
unpatentable over Uszok et al. (U.S. PubHcationNo. 2004/0205772) in view of 
Kou2aietsov et al. (U.S. Patent No. 6,931,546). Applicant respectfully disagrees with 
sfuch rejection, especially in view of the amendments made hereinabove to the 
independent claims. Specifically, applicant has amended the independent claims to at 
lea^ sub£(tantially include the subject matter of fotmer dependent Claims 8, 9, 10, 93, 94 
etal. 

With respect to the independent claims, the Examiner has relied on paragraphs 
0014^ 0050, and 0055 from the Uszok reference to make a prior art showing of 
applicant's claimed technique '"receiving code to receive at said destination computer 
operation specifying XML data sent by said source computer^ (see this or similar, but not 
necessarily identical language in the independent claims). 

Applicant respectfully asserts that the excerpts &om Uszok relied upon by tlie 
Examiner discloses a teclinique where " Ftlhe chent side — mBot— implcmaits a 
presentation layer, active contponent or even pure XML or HTML, and may have 
multiple presentations for different platforms " (emphasis added). However, having the 
client side implement pure XML shnply fails to meet a * deceiving code to receive at said 
destination computer operation specifying XML data sent bv said source computer^ ' 
(emphasis addedX as claimed by applicant, 

In the latest Office Action dated 03/08/2006, the Examiner has further argued that 
"the plug-ins can be passed from the botServer manager to plug-in manager, which is the 
target process" and that "[b]oth managers are performed at the same target computer 
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botServer." Additionally, the Examiner cited the following excerpts ftom Uszok to 
support such assertion. 



4» 




jj^ jr*- JP» 




(uszok. Figure 4) 



^[0079] Plug-ins: The botServer standard services can be extended 
by a mechanism of plug-ins. A plug-in is a software component 
installBd by botServtir administrator within the plug-ins manager 
(450) which communicates with other plug -ins and bots via the 
botServer manager 402 using messages. From the usability point of 
view, a plug-in is somewhat similar to a bot"-it has an unique 
ID, understands bot messages, participates in protocols etc. A 
plug- in, however, never migrates ^ cannot be automatically 
downloaded and installed, and usually has much higher system 
security permissions. A plug-in also may possess any number of 
system threads (since it doesn't have to strictly adhere to a 
request-response execution schema) . Plug-ins are usually used to 
interface with vairious external systems, perform demanding real- 
time operations and provide other services. For example, FIG. 4 
illustrates a plug-in 454 for interfacing with an SAP server 462. 
Another plug-in 452 interfaces with a legacy system 460 such as 
an enterprise database running on a mainframe. FIG, 17 shows 
auction and B2B plug- ins on botServers. 



[0090] Plug-ins may be configured so that they have the same ID 
on every server. That strategy relieves bots from having to 
search for an appropriate plug- in if they knov/ the requested 
plug -in ID. Some standard system services (e.g. ontology service 
1620 or botDNS 442) may be in5)lemented as plug- ins as well. 
Specialized plug- ins can be created by botserver owners to 
provide services that make the server more attractive to bots 

(e.g. in order to advertise some other profitable services) . 
Other exan^les shown in FIG. 4 (and FIG. 16) are knowledge 



PA(£27/36'RCVDAT8»1/2006 6:45:47PM [Eastern D^^^^ 



AUG. 31. 2006 4:02PM ZILKA-KOTAB, PC 

-21- 



NO.4050 P. 28 



management service 1620, matching service 1€42 and a 
publishing/event service 1^50, Generally the plug-ins should be 
created to be compatible with botServer scaling." (UB2ok, 
Paragraphs 0079^ 0080 - emphasis added) 

Applicant respectfully asserts that the additional excerpts fiiom Uszok relied upon 
by the Examiner simply disclose that "[a] plug-in is a software component installed by 
botScrv^ administrator within the plug-ins manager (4S0) whi^^ f^nnrin^nnicates with 
other plug-ins and bots via the botServer manager 402 using messages" (emphasis 
added). However, the "get/set data" and ^hises" flows that communicate wifii the plug-ins 
and bots 'Hising messages" in Uszok's Figure 4 fails to disclose ^'receiving code to 
receive al said destination computer operation specifying XML data sent by said source 
computef ' (emphasis added), as claimed by applicant hi addition, Us2Xik disclosure that 
'*[b]oth managers are performed at the same target computer botServer" (emphasis 
added) simply feils to meet * ^ecciving code to receive at said destin ation computer 
operation specifying XML data sent bv said source computer^ ' (emphasis added), as 
claimed by applicant. 



In addition, with respect to the independent claims, the Examiner has relied on the 
following excerpt from the Uszok reference to make a prior art showing of appUcant's 
claimed **parsing code to parse said operation specifying XML data to identify one or 
more complex data types within said operation specifying XML data" and '^matching 
code to match each complex data type with an associated execution process available to 
said destination computer" (see this or similar, but not necessarily id(mtical language in 
the independent claims). 



^[0057] Returning now to the hot code acquisition process, the 
botServer 350 may already have a copy of the corresponding sBot 
class for operation with the mBot. (Indeed, the botServer 350 
could even be hosted on the same site as the hot developer site 
310.) If BO, the botServer 350 creates an instance of the 
requested sBot eind assigns an identifier to it corresponding to 
the mBot that made the request. If the appropriate sBot code is 
not already present, the botServer 350 obtains the appropriate 
sBot code from the hot developer site 310 by download link 362, 
Authentication of that code, security issues, payment and other 
particulars are discussed later in this description* At the 
botServer/ after the sBot Is i&stallad, a mesBage originating 
from botVaster 320 is comimmiGated to the sBot code to initialize 
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it to carry out the task requested by the user." (Uszok, 
Paragraph 0057 - emphasis added) - 

Applicant respectfully asserts that such excerpt from Uszok relied upon by fiie 
Examiner merely teaches that the ^ 'botServer 350 creates an instance of the leonested 
sBot and assigns an identifier to it corresponding to the mBot that made the request'^ 
(emphasis added). Additionally, the excerpt from Uszok discloses that "[a]t the 
botServer, after the sBot is installed, a message originating from botMaster 320 is 
communicated to the sBot code to initialize it to carry out the task requested by the user" 
(emphasis added). However, creating an sBot instance and initializing it from "a 
message originating from botMaster" simply fails to meet a technique of ' 'parsing code to 
parse said operation specifying XML data to identify one or more complex data types 
within said operation specifying XML data'* (emphasis added) and ' hatching code to 
match each complex data type with an associated execution process available to said 
destination computer*' (emphasis added), as claimed by applicant. 



In the latest Office Action dated 03/08/2006, the Examiner has fuiflicr argued that 
"Uszok states matching mechanism (0133) and the XML-based interaction protocols 
define a set of states that a bot may exist in, rules of transition from one state to another 
and a description of the schema of data that can be exchanged between participating 
parties in order to transition from one state to another (128)." Additionally, the Examiner 
cited the following excerpts from Uszok to support such assertion. 



" [0128] A meeting place in the present system is a separated 
logical area of the botServer, where bots can interact with 
chosen types of other bots and plug- ins according to defined 
interaction protocols. Interaction protocols define a set of 
states that a bot may exist in, rules of transition from one 
state to another and [optionally] a description of the structure 
(schema) of documents (data) that can be exchanged between 
participating parties in order to transition from one state to 
another. An interaction protocol can be described, for example, 
in an XML-based language. The selected protocols are in^ilemenced 
on bot's and plug -ins in accordance with the present invention. 
(Uszok, Paragraph 0128 - emphasis added) . 

^ [0133] I4atching id a general mechanism that enables selection of 
abstract "offers" that most closely match abstract "requests." 
The mechanism is abstract, because it does not define what the 
offer really is. The determination is baaed only on its 
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deecripblon and applying sophisticated Al algorithms to actually 
perform matching, however XHL-baeed^ "hard" --regular expression 
or dOL-like basttd, matching might he used as well (whichever more 
useful in a given, situation). Such an approach allows, e,g,, 
selecting botservers providing most -appropriate services, or 
selecting trade offers closest to the buyer's requirements— all 
using the same mechanism. Generally the matching service should 
be able to provide a match of request and offer even if they 
cannot be matched by simple comparison.' (Uszok, Paragraph 0133 - 
emphasis added) , 



Applicant lespectAilly asserts that the matching disclosed in the exceipts firom 
Uszok relied upon by the Examiner teach that a "determination is based only on its 
description and applying sophisticated Al algorithms to actually perform matching, 
however X ML-based "hard"-regular expression or SQl^like based, matching miefat be 
used as well' ' (emphasis added). Generally disclosing XML-based matching fails to meet 
''matching code to match each complex data type with an associated execution process 
available to said destination computer '' (emphasis added), as claimed by apphcant 
Further, Uszok' s disclosure where "an interaction protocol can be described, for exanqjle, 
in an XML^based language '' simply fails to meet ^ 'parsing code to parse said operation 
specifydng XML data to identify one or more com plftv riafa types within said opa^tion 
specifying XML data'* (emphasis added), as claimed by applicant. 



Further, with respect to the independent claims, the Examiner has relied on the 
following excerpt from the Kouznetsov reference to make a prior art showing of 
appHcant's claimed technique * Vherein said execution process maps configuration data 
specified within said operation specifying XML data to a configuration data store of said 
destination computer; wherein said configuration data store is one of: a Windows 
Registiy entry; an INI file; a DAPI store; and a database entry*' (see this or similar, but 
not necessarily identical language in the independent claims). 

^The above limitations of the prior art are addressed by a 
system, method and software in which a process is run on a client 
machine having sufficient privileges to execute privileged 
processes. This process has a role of a "local system" and is 
effectively an administrator for the machine. An agent program 
rvinning in user-mode provides a generic interface- The agent 
includes an application prograsndbog interface ("API") for 
receiving requests for privileged processes. The agent includes 
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an interface co the privileged process as well. The agent 
includes methods for authenticating any received requests and 
will only fonvard a request to the privileged process upon 
determining that the requesting application has sufficient trust. 
Hence, the agent provides a level of indirection in accessing the 
privileged process so that the local system interface is not 
exposed directly to untrusted entities . 

Briefly stated, the present invention involves a system for 
providing application services in a computing environment having 
both user-mode processes and privileged-mode processes. An agent 
executes in privileged mode and exposes an interface to user-mode 
processes . A user- mode component is provided with an interface 
configured to access the agent ^s exposed interface. A 
configuration coniponent specifies a list of installable code 
con^onentg that are authorized for installation, wherein the 
agent will only execute privileged-mode functions in response to 
accesses by the user-mode code coxiiponent when the installable 
code coaiponent is represented on the list.' (Kouznetsov^ Col, 4, 
lines 25-54 - eityphasis added} 

Applicant respectfully asserts that the above excerpt fiom Kouznetsov rdied upon 
by the Examiner teaches that an ^ agent includes an application programming interface 
(" API "^ for receiving requests for privileged processes ' (emphasis added). In addition, 
Kouznetsov discloses a "configuration componoit [which] specifies a list nf installable 
code components fliat are authorized for installation, wherein the agent will only execute 
privileged-mode fimctions ui response to accesses by the user-mode code component 
when the installable code component is represented on the list" (emphasis added). 
However, disclosing an API with a configuration component simply fails to meet 
applicant's claimed technique 'Vherein said execution process mans configuration data 
specified within said operation specifying XML data to a configuration data store of said 
destination computer " (emphasis added), in the context claimed- In addition, 
Kouznetsov's disclosure of '^[a] configuration component speciflying] a list of installable 
code components" (emphasis added) in no way meets a technique ^'wherein said 
configuration data store is one of: a Windows Reristrv entry: an INI file: a DAPI store: 
and a database entrv^ ' (emphasis added), as claimed by applicant. 



Additionally, with respect to the independent claims, the Examiner has relied on 
the following excerpt from the Uszok reference to make a prior ait showing of applicant's 
claimed technique *Svherein an identifier of an execution process within said complex 
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data type includes at least one of: data specifying a computer file to trigger said execution 
processj data specifying a communication channel to trigger said execution process; and 
data specifying an operating system command to trigger said execution process" (see this 
or similar> but not necessarily identical language in the independent claims). 



''[ooeel Referring again to FIG. 5, establishing a botBox is 
initiated by the user or prompted by botMaster through the GUI 
520. The GUI comitiunicatea via the botMaster core 530 to a botBox 
proxy component 542. The botBox proxy componezit initialiaeo local 
botBox storage 536 through the botHafiter configuration component 
534 and then utilises a donmuni cation manager 544/ and more 
specifically a bot£ox coomunicator companent 546, to aend a 
message to request initialization o£ a corresponding botBox on a 
botServer. Any faotServer (with botBox facilities) can be used. 
Preferably, the user will vrant to select a botServer with high 
availability if the user botCs) need to operate arovmd the clock. 
Bote with more modest requirements can have their botBoxes hosted 
at more modest botServers, or even on their own home PC. The user 
can relocate botBox later if desired, and could store it 
(including all hot information) on machine -readable media for 
subsequent uploading on another platform. For commercial 
applications, botBoxes should be housed on a reliable server, 
preferably independent of the user platform. This architecture 
supports operation of the user*s bots while the user is off-line, 
and ensures the user's privacy." (Uszok, Paragraph 0068 - 
emphasis added) 



Applicant respectfully asserts that the above excerpt from Uszok relied upon by 
the Examiner discloses that **[t]he botBox proxy component initiahzes local botBox 
Storage 536 through the botMaster configuration component 534 and then utilizes a 
commuoication manager 544 ... to send a message to request initialization of a 
coiresponding botBox on a botServer' ^ (emphasis added). However, "said[ing] a 
message to request initialization of a corresponding botBox*' fails to meet a technique 
'^vherein an identifier of an executio n process within said complex data tvoe includes at 
least one of: data spedfyititg a computer file to trigger said execution process; data 
specifying a conrniunication channel to trigger said execution process; and data 
specifying an operating system command to trigger said execution process'* (emphasis 
added), as claimed by applicant 



In addition, with respect to independent Claim 16, the Examiner has relied on 
paragraphs 0014, 0050, and 0055 from the Uszok reference to make a prior art showii^ 
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of applicant's claimed "data fonning code to foim at said source computer operation 
specifying XML data containing one or more complex data types" (see this or similar, but 
not necessarily identical language in the independent claims). 

Applicant tespectfiilly asserts that the excerpts j&om Uszok rehed upon by the 
Examiner discloses a technique where " ftihe client side — mBot— implements a 
presentation layer, active component or even pure ^CML or HTML, and may have 
multiple presentations for different platforms" (emphasis added). However, having the 
client side implement pure XML simply fails to disclose the technique of " data forming 
code to fonn at said source computer operation sp&c^fvin^ XML data containing one or 
more complex data typ es" (emphasis added), as claimed by applicant. 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references ^emselves or 
in the knowledge generally available to one of ordinary skill in the art, to modify flie 
referefiice or to combine reference teachings. Second, Ihpre must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations. The teaching or suggestion to make the 
claimed combination and the reasonable expectation of success must both be found in the 
prior art and not based on applicant's disclosure. In re VaecK9Al F.2d 488, 20 USPQ2d 
1438 (Fed.CSr.1991). 

Applicant respectftdly asserts that at least the third element of the prima facie 
case of obviousness has not been met^ since the prior art references, when combined, Ml 
to teach or suggest aU of the claim limitations, as noted above. Nevertheless, despite 
such paramount dejRciencies and in the spirit of expediting the prosecution of the present 
application, applicant has amended the independent claims to at least substantially 
include the subject matter of former dependent Claims 8, 9, 10, 93, 94 et al. 

With respect to the subject matter of former Claim 9 et al. (now at least 
substantially incorporated into the independent claims), the Examiner has reUed on the 
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following excerpt ftoin tbe above Uszok refcx^ce to make a prior art showing of 
applicant's claimed technique *S;rtierein said result data includes data specifying existing 
configuration data of said destination computer" (see this or similar, but not necessarily 
identical language in the independent claims). 



'»[0122] The user may choose to cneate the dynamically created, 
temporary profiles baaed on existing ones- The teniporary profile 
is used for a limited amoimt of time (specified by timeout, 
response type, or any other kind of trigger) or per- transaction 
and after that it is destroyed. This allows the user to block all 
the later communication attempts {especially spam) with a 
particular prof ile-- they will fail because the profile does not 
exist anymore. It also supports the anonymity in the hot systems- 
it is difficult (if possible at all) to track a person using the 
dynamic profile . The user may also choose to define the 
information filters on each user profile* Any information flow 
going through the profile may be analyzed (e.g., checking the 
sender, analyzing the message content, etc.) and rejected if does 
not fit to the rules defined in the filter. This allows an 
additional anti-spam mechanism to be built into the user 
profiles. The rejected information is not routed to (and from) 
the user account (optionally only notifying it about the 
information rejection)* (Ussjok, Paragraph 0122 - eniphasie added) 



Applicant respectfully asserts that the excerpt from Uszok above relied upon by 
the Examiner merely teaches that "[t]he user may choose to create the dynamically 
created, temporary profiles based on existiAg ones " However, there simply is no 
mention in flie above excerpt of a technique Vherein said result data includes data 
specifying existing configuration data of said destination computer' ^ (emphasis added), as 
claimed by applicant. 



In addition^ with respect to the subject matter of former Claim 10 et al. (now at 
least substantially incorporated into the ind^endent claims), the Examiner has relied on 
the following excerpt &om the above Uszok reference to make a prior art showing of 
applicant's claimed technique 'therein said execution process maps existing 
configuration data of said destination computer stored wilhin said configuration data 
store of said destination computer to said result data to be returned to said source 
compute" (see this or similar, but not necessarily identical language in the independent 
claims). 
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*[Oiooj FIG. 11-B illustrates a maeter-slave arrangement for 
sliariA9 a botBox. Here, the user installs a botMaeter application 
1119 on a portable device such as a PDA, cell phone, or 
automobile internet appliance. This may be a "thin client" with a 
sin^lified user interface (perhaps with limited graphics) , and it 
may lack the aoftwaro and memory necessary tor creating and 
maintaining a u^er model. This botMaater 1H8 need not establish 
ita own botBox account. Rather, the ^'thin*' botMaater can interact 
with the same botBox 1112 that was established by the office 
botMaster 1110. The portable botMaster, in a slave mode, employs 
the user model maintained by the master botMaster 1110 and the 
portable program assigns to its mBots one o£ the user profiles 
made available on the shared botBos 1112, Creating new profiles 
or modifying existing ones can be done using the more full- 
featured office botMaster lllO-*' (uszok. Paragraph 0100 - 
ei^phasis added) 



Applicant respectfully asserts that the excerpt fix>m Uszok above relied upon by 
the Examiner teaches that "[t]he portable botMaster, in a slave mode, employs the user 
model mai ntained by the master botMaster 1 1 10 and the portable program assigns to its 
mBots one of the user profiles made available on the shared botBoi^ l 1 12" (emphasis 
added) since "it may lack the software and memoty necessary for creating and 
maintaining a user modeP (emphasis added). The disclosure of "employ[ing] the user 
model maintained by the master botMast^' simply fails to even suggest a technique 
*Svherein said execution process mans existing configuration data of said destination 
compute stored within said configuration data store of said destination computer to said 
result data to be returned to said source comnuter '* (emphasis added), as claimed by 
applicant. 



With respect to the subject matter of fotmer Claims 93 and 94 (now at least 
substantially incorporated into the independent claims), applicant respectfully notes that, 
in the latest Office Action dated 03/08/2006, the Examiner failed to specifically respond 
to these claims presented in Amendm^t A mailed 12/12/2005. Applicant has reviewed 
the Uszok and Kouznetsov references in their entirety and asserts that such claim 
language is simply not met by such references, either alone or in combination. 
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Huis, a notice of allowance or specific prior art showing of each of the foregoing 
claim elemaits, in combination with the remaining claimed features, is respectfiiUy 
requested. 

Hxus, all of the independent claims are deemed allowable. Moreover, the 
remaining dq>cnd«it claims are furthCT deemed allowable, in view of their dqp«idence 
on such indqpendent claims. 

In the evmt a telephone conversation would expedite the prosecution of this 
apphcation, the Examiner may reach tiie undersigned at (408) 505-5100. The 
Commissioner is authorized to charge any additional fees oi credit any oveipaymoit to 
Deposit Account No. 50-1351 (Order No. NAI1P480). 




Res^tfUUjrsubmitted, 
ZiB^-Kot^PC. 



P.O. Box 721120 

San Jose, CA 95172^1120 

408-505-5100 



ion No. 41,429 
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